The development of software is generally done as a series of software builds, also known as development builds, dev builds, or just builds. A build may refer to a process of converting source code files into standalone software artifacts capable of being run by a computer, or the result of such a process. Thus, during the creation of software, developers may create many different builds, such as weekly or even daily builds, before reaching a final product.
As can be appreciated, a single computing machine is often unable to manage and store many builds during the development of software, and arrays and other external storage devices may be utilized. However, although the arrays may provide enough storage for a development environment, conventional systems require the copying and moving around of build data to developers requesting the data. Such moving and copying, often manual processes, may not be feasible for many software development environments, such as software development environments that include many software developers creating and modifying many builds over a network.
Also, application developers, testers, and others often debug, test, validate, or perform quality assurance of a new application using a copy of a production database. To do so, a tester may obtain a backup copy of a production database that an existing production application is actively using. The tester then validates that his new application performs as expected and interacts with the test copy of the database in the manner that is expected, e.g., using test scripts. To ensure that the testers have reasonably current data, database administrators may be asked to “refresh” a test copy of a database on a regular basis (e.g., daily or weekly), which means overwriting an existing test copy using a more recent copy of the production database. Also, there may be other times outside of the debugging, testing, and quality assurance context when a database administrator needs to provide a temporary copy of a production database at an end-user's computing device via a database refresh operation.
Current methods to refresh or otherwise copy a database can consume substantial processing, storage and network resources. For example, in order to refresh a test database, a database administrator may oversee backing up a production database from a production server to a backup server, compressing the backup copy, copying the backup copy to a test server, decompressing the backup copy, and/or restoring a test copy at a test server. A conventional process like this may require substantial manual intervention by the database administrator. Moreover, since commercial databases can reach terabytes of data, a conventional refresh process can result in substantial delays and/or service interruptions at the production server, backup server, and/or test server. A conventional refresh process may also consume substantial network and data storage capacity because it transfers a full copy of the production database over a network and restores it at a new location.
There is a need for a system that overcomes the above problems, as well as providing additional benefits.